CI: GitHub Actions workflow for the Python sample - #3

What this changes

Adds .github/workflows/python.yml: the first CI workflow in the repository,
covering the python/ sample. One workflow per sample implementation, named
after the sample — a second language sample lands as a sibling file
(dotnet.yml, swift.yml) rather than as another dimension of one big matrix.
A header comment in the file records that convention.

The workflow runs the two commands python/README.md already documents, and
nothing else:

3.11 is the floor because pyproject.toml sets requires-python >= 3.11.

Details worth knowing:

• Path-filtered to python/** plus the workflow file itself, so editing the
  spec, the registry or a proposal starts no runs.
• defaults.run.working-directory: python, so each step is literally the
  command from the README — no wrapper scripts to drift out of sync.
• fail-fast: false, so one Python version failing does not hide the others.
• permissions: contents: read; pip cache keyed on python/pyproject.toml.
• Concurrency cancels superseded pull request runs, never main runs.
• workflow_dispatch for manual runs.

Also adds the status badge and a short CI note to python/README.md.

Verified before opening this

Installed the sample into clean virtualenvs on 3.11, 3.12 and 3.13 and ran the
exact step sequence from the python/ directory. All three: 41 passed, 1
skipped, ruff clean. The skip is test_rowingdata_golden_file_if_present,
which looks for ../rowingdata/testdata/rowingdata_standard_example.fit; that
file is not in this repository, so it skips on CI by design.

Two things deliberately left out

1. ruff format --check is not a gate. It currently fails on
   src/rowing_data/reader.py, src/rowing_data/validation.py,
   tests/sample_sessions.py and tests/test_fields.py. The documented check
   is ruff check alone, so gating on formatting would have meant either red CI
   on day one or reformatting code outside the scope of this change. Easy to add
   in a follow-up if wanted.
2. No "fixtures are reproducible" check. Regenerating
   tests/fixtures/stroke-boundary.fit from tests/generate_fixtures.py
   produces different bytes than what is committed (b9af16d8… committed vs
   172a9072… generated); gps-update.fit reproduces exactly, and repeated
   runs are deterministic, so the committed file appears to predate a code
   change rather than being nondeterministic. Interop tests still pass because
   they assert semantics, not bytes. For a repository where sample files are the
   evidence, a byte-reproducibility check is worth having — it needs that
   fixture regenerated first, which belongs in its own pull request.

Class of change

• Editorial — typo, formatting, or wording that changes no requirement
• Substantive — new or changed field, changed conformance requirement,
  changed compliance level. Requires a linked proposal.
• Structural — governance, licensing, repository scope
• Repository plumbing only — templates, CI, docs about the process

Links

• Issue: —
• Proposal: —

Compatibility

Does any existing conforming file become non-conforming, or change meaning?

• No
• Yes — described below

No specification text, field ID, scale or unit is touched. This adds CI
configuration and a README note only.

Checklist

• One logical change — no unrelated fixes bundled in
• Paragraphs I did not change are not reflowed (keeps the diff readable)
• registry/field-ids.md updated, if any field ID
  is touched — n/a, no field ID touched
• Linked issue closed or updated, if this resolves one — n/a
• RFC 2119 keywords are deliberate, and state producer and consumer
  obligations separately where they differ — n/a, no normative text
• Version number in spec/FIT_STANDARD.md not changed — versions are
  assigned at release
• Implementation evidence linked, for anything that changes file contents —
  n/a, no file contents change; local run results above